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ABSTRACT 

The phrase "student computer dialogs" refers to 
interactive sessions between the student and the computer. Rather 
than using programing languages specifically designed for computer 
assisted instruction (CAI) , existing general purpose languages should 
be emphasized in the future development of student computer dialogs, 
as the power and flexibility of general purpose languages make their 
extension more useful to a larger proportion of computer 
installations. Two programing languages have been used at the 
University of California at Irvine — HETASTHBOL, the assembly language 
used on the Xerox Sigma 7, and FORTRAN. A number of small modules 
have been written in these two languages, and more are being 
developed. Technological advances in hardware may soon lead to 
stand-along systems for student computer dialogs, thus making 
small-scale programs mote important. An example of one module 
developed at Irvine is provided. (DGC) 
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By a student computer dialog we mean a "conversation" between 
a student and a computer device, possibly a terminal or display. 
In such a dialog the computer is "talking" with the student, 
either asking questions and waiting for answers, or responding to 
requests from the student. This type of usage is sometimes 
referred to as computer-assisted instruction or CAI. But, because 
of the intrinsically wider connotation of the term, due to the 
way computers can be used in instruction, we prefer to call 
such interactions dialogs . The model for a student-computer 
dialog is what goes on between the student and the instructor 
in the instructor's office. We cannot hope to obtain this flexi- 
bility with current day computer techniques, with sizable numbers 
of students, but we can, experience shows, approach a reasonably 
good approximation, particularly if very skilled teachers are 
responsible for preparing the student-computer dialogs. In 
areas where the computational skills of the computer are important, 
we can offer resources not available to the instructor in such 
office conversations. 
Standard Approac 

A typical way this problem has been attacked in the past is 
to develop a special purpose language for preparing such dialogs. 
Dozens of such languages have been developed, although few have 
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had wide-scale acceptance. The original language to attain wide- 
usage was Coursewriter, developed by IBM at Yorktown Heights. 
Coursewriter is still in existence both on IBM computers and on 
a variety of other systems (such as Hewlett-Packard). Other 
examples of such special languages aie PLANET, PILOT, and DITRAN. 
Perhaps the most extensive language of this kind ever developed 
is TUTOR, used as the basis of the PLATO Project at the University 
of Illinois. 
A lternate Approach 

An alternate to developing special languages is to work 
within existing languages and to make extensions to these languages 
to make them easier to use in preparing dialogs. There is nothing 
new about this approach — dozens of attempts have taken this or 
related directions — but this approach has achieved far less 
publicity than the special purpose languages. Indeed a document 
I saw recently attempted to define "hardcore CAI" as something 
that was written in a special purpose language developed just for 
this purpose. This seems to be an unfortunate attitude. The 
student running the dialog does not necessarily know anything 
about the language facility in which the dialog was prepared; 
many dialogs currently in use could have been written in a wide 
variety of languages Including many of the standard all-purpose 
languages. So the software involved is not a basis for classif icatio 

Advantages exist in working within available languages. 
First, these languages exist and survive because they are powerful 
languages at least for some purposes.^ The facilities these 
languages include would, in many cases, need to be present in any 
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lul3y developed dialog language, and so would have to be dupli- 
cated. Thuc, computational facilities such as those in FORTRAN, 
ALGOL, or PL/1 would very likely be required in dialogs in physics 
and in other areas of science. Some of the special purpose 
languages could provide these facilities by allowing "exits" or 
hooks to general purpose facilities, and many languages allow 
this. But working directly within general purpose languages 
gives another way of attaining these necessary facilities. 

Another distinct advantage of working with existing languages 
is that we can mold the facilities required on pedagogical demand, 
rather than through theoretical arguments on language design or 
the way things should be taught. Thus, this approach can allow 
different authors, teachers from different backgrounds, to create 
quite different kinds of learning materials. Then these programs 
can compete in the educational marketplace. New facilities can 
be added to meet author demands. Thus, in our case the addition 
of graphic capabilities, essential for teaching applications, was 
possible with reasonable effort. 

Furthermore, some of these general purpose languages allow 
access to all the resources of the computer, while special 
languages often restrict such resources. Thus, the ability to 
use ovf;rl,iy facilities may not be possible in such special soft- 
ware, hxit this facility or c»ne equivalent to it will be 
important for developing very large dialogs. Further, because 
there is no 'language," no single language, no fixed pedagogica7<. 
style is impcsod on course authors; existing "CAI" languages 
often were developed with a particular pedagogical approach ip. 
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mind, a predetermined view of how to use the computer in learning. 
A more general set of facilities does not restrict the author 
with regard to teaching styles but allows individual teachers to 
proceed in ways that seem reasonable to them. 

There are clearly, however, some disadvantages and problems 
in using general- purpose languages for dialogs. The first serious 
question is just how we tag the new facilities, needed for an 
efficient dialog authoring process, onto an existing language. 
The mechanism for doing this in the available language may be 
rather clumsy; subroutine calls, for example, are often not 
flexible. Furthermore, these extensions may not be at all easy 
to transport from one machine to another, and so the movement of 
materials to new environments may not be an easy task. 

However, these disadvantages will be overcome by developments 
in hardware and software in the next few years. At the present, 
I believe, a sufficient amount of good, well-tested material does 
not exist in most subject areas. By the time such material is 
available the hardware situation will be different, and so the 
transport problems will be different. 
T he Irvine Dialog Approach 

As Indicated, working with existing powerful languages 
allows a great number of variants. For the remainder of this 
paper I describe the variants in software and authoring that we 
have employed at Irvine in the Physics Computer Development 
Project. 

First, our critical beginning point is with teaching materials, 
produced by competent teachers. The idea is that software develop- 
ment does not precede the development of learning sequences, but 



-5- 



follows such development. Thus, competent teachers write the 
dialogs first, in a form which is not language-dependent, and 
then we develop whatever new software facilities are necessary 
for getting those dialogs running* The older facilities developed 
for previous programs will typically still be useful, and many 
programs will not demand new facilities. But on the other hand, 
some programs may require extensive new software. This turning 
about of the usual direction (first languages, then courseware) 
with special purpose languages serves to emphasize that our 
primary purpose is the development of teaching materials , not the 
development of languages. 

Furthermore, as indicated above, we wanted to make use of 
all the facilities on a general purpose, multi-language, timesharing 
computer. That is, we did not want to restrict ourselves to a 
subset of the possibilities on the machine. 

In view of these objectives we have worked at Irvine in two 
general purpose languages, producing dialogs which are combinations 
of these two languages. The first, and perhaps most important, 
language is M^TASYMBOL, the assembly language available on the 
Xerox Sigma 7 we use. The second is the well-known general 
purpose scientific language, FORTRAN. 

The extension mechanism that we use in the assembly language 
is the macro or, as referred to on the Sigma 7, procedure. Thus, 
a typical segment of code for a dialog will consist of macro 
calls. All of these have English language command names, and in 
general our policy is to have few arguments in the macro. New 
macros are written only in response to pedagogical demand. 



ERIC 



6 



-6- 



We can get a better idea of what this looks like if I show 
a fragment of a program, explaining what the statements mean. 

I will begin with the dialog as formulated by the authors. 
The example I use was generated at a workshop at Irvine for 
University of California physics faculty from other campuses. 
It was a group activity (involving Richard Ballard, Irvine; 
Sun Yiu Fung, Riverside; Peter Geisler, Davis; Bruce Rosenblum, 
Santa Cruz; and Robert Eisberg, Santa Barbara) intended to illus- 
trate the process of creating dialogs. We began with a flowchart, 
a fragment of which is produced in a much reduced version here. 



ERLC 



7 



BEST COPY mim 



^^w.-4, ^ ^^^^ 



7 







1- ^5-» 






8 




Note that the authors produced only rough sketches of the 
drawings required. The flowchart then went to a student programmer 
sometimes a secretary will also play an intermediate role, entering 
much of the program directly from the flowchart. 

The following segment of code corresponds to the flowchart 
segment. The macro calls are apparent; most of the macros have 
English language names, and their functions in most cases are 
obvious, particularly if you refer to the flowchart. Thus, WRITE 
produces terminal output, DELAY adds timed delays, SKIP skips 
lines on the screen, RESET makes a variable zero, CURSOR turns 
on the crosshairs for graphic input, BUMP increments a variable. 
Some of the macros are particularly concerned with graphics; 
WINDOW determines the active area of the screen, SCALE establishes 
user coordinates for this area, CURVE draws a curve, ARROW draws 
an arrow. 
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Note that FORTRAN is also used in the preparation of dialogs. 
FORTRAN subroutines are callable from the macro-based portions of 
the programs, and some of the facilities of the acros are callable 
from FORTRAN. The primary use of FORTRAN is for calculation, the 
area in which it is particularly strong. We can make extensive 
use, too, of the available FORTRAN subroutine libraries. For 
example, a number of our Irvine dialogs include programs from the 
Scientific Subroutine Package, a common collection available on 
most sizable machines. 

We believe that this combination of macros plus FORTRAN 
allows us the advantages mentioned above, without our developing 
a special purpose language. To some extent the dialog commands 
are a special purpose language (the term "language" does not have 
precise meaning), but the emphasis is very different from what is 
usual in language construction. The primary difference is that 
It is a growing set of facilities, growing by pedagogical demand 
rather than an entity defined in advance. Further, we do not 
assume that the teacher will be familiar with these language 
facilities. 
Future ^* 

First, the most obvious comment to make about .the future 
Is that the Irvine dialog facilities are always developing. We 
are at the moment, for example, writing an elaborate new set 
of macros having to do with symbol manipulation and parsing 
of "complicated expressions involving complex numbers and operators. 
These macros like others that have been developed are being coded 
because they are necessary for the dialogs currently under develop- 
ment at Irvine. 
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Slnce we are working in a general purpose environment, we 
can use other software facilities in che machine besides those 
already employed. The most promising, particularly for some of 
our new applications which combine computer management along 
with computer dialogs, are the full database facilities available. 
These, like any other software in the machine, can be called 
within macro-based code, and so programs can use this database 
facility in rapidly developing new facilities in this area. 
We are planning such development at this time, with emphasis on 
course management. 

If we look a little further into the future, we can see other 
exciting possibilities. While we are currently working in an 
assembly language, there is increasing interest in system 
development work within a systems programming language. While 
valid questions can be raised about the efficiency of code produced 
by such languages, and the practicality of this approach, it is 
an interesting one to explore for the future. Hence, one might 
see the possibility of developing facilities like those described 
for the Irvine dialogs within a high level system programming 
language, perhaps as a structural addition to the language. 
Other languages, as indicated, could still be used. If a single 
system programming language gains general acceptance, then this 
might ease the process of transferability; but this possibility 
does not look likely. 

A more likely development for the future of educational 
computing, perhaps, is the rise of widespread use of stand-alone 
systems, displays having within them most of the processing 
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capabilities that they will usually need. These systems, unlike 

timesharing systems, will be used by individual students. So if 

a particular machine breaks down, only that student will be 

affected, and not the hundreds of students who might be affected 

in a timesharing environment. There are also great advantages 

with this type of machine with regard to graphic display capabilities. 

If such machines become common in the educational evironment 
in a period within five to ten years from now, the task of pre- 
paring and testing the interactive software and the dialogs will 
probably still go on in the larger timesharing systems that we 
are already developing. Hence, software systems such as I described 
may still play a role in generating the programs for the small 
machines. 
Conclusions 

I presented here an alternate to the development of a special 
purpose language for student computer dialogs and examined possibilitie 
for the future. We believe a system of this kind is effective 
for generating highly interactive material valuable for students 
in the learning process. 

The work described here is supported by the National Science 
Foundation and the University of California. A bibliography and 
docimientation of the underlying software and of individual dialogs 
are available on request. 
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